perf(gc): stop re-marking a heap where nothing dies — yield-adaptive major pacing + the evacuation move-hook mutex - #7733

gc-handoff/bench/retain.ts builds a 3 M-element array of {a, b} records,
keeps every one of them live, then sums a field. Nothing is ever garbage,
and Perry spent 1.26 s of a 1.31 s run inside the collector — 96%. Node
does it in 0.14 s.

Two independent causes, both measured on the pinned quiet M1 mini against
origin/main @ c156f8a41.

1. Half the pause was two full mark-sweeps that reclaimed 4 MB between them

PERRY_GC_TRACE=1 ./n_retain on main:

arena_growth_full_escalation_due escalates a minor to a full once arena
live-bytes pass K× (K = 2) the live set measured after the last full. Its own
doc-comment claimed a "legitimately large stable live set (retain-style) does
not over-escalate — its arena hovers near its own baseline". retain's live
set is not stable, it grows: every doubling crosses the threshold, and each
resulting full marks a heap where nothing has died. 644 ms of pause for 4 MB,
and the second one moved arena in-use by exactly zero.

So price a full by what it reclaims. A full that shrinks arena in-use by less
than 20% shifts the next escalation threshold left by one — capped at 2, so the
multiplier tops out at 8× — and a productive full resets the shift to 0 in one
step. The yield is measured on the same metric the escalation gate reads,
so the two cannot disagree about whether a full helped, and it is scoped to
escalated fulls: an explicit gc() never moves the backoff, or a
gc()-in-a-loop test would drive it to the cap. Old-gen garbage is unaffected
— old_reclaim_pressure_due still forces its own full.

2. Every evacuated object took a process-global mutex to hash an empty map

object_static_prototype_owner_moved — the ObjectOverflowFields move hook,
run once per moved object — took a Mutex<HashMap<usize, u64>> and ran a
SipHash remove against the residual Object.setPrototypeOf registry.

That registry is empty in any program that never re-prototypes a
non-meta-capable owner, and a latch already says so: OBJECT_PROTOTYPES_NONEMPTY,
stored Release before the insert, and read by both siblings
(object_static_prototype, prune_dead_object_prototype_owners). The move
hook was the one reader that skipped it, so a 3 M-record promotion paid 2.5 M
lock/unlock pairs and 2.5 M hash probes against an empty map. It is why a
single-threaded benchmark profiled with pthread_mutex_lock and
std::hash::random::RandomState in its top ten.

Isolated without a second build by retain_latched.ts, a twin that latches the
registry through a RegExp owner: on this binary retain is 0.81 s and
retain_latched 0.84 s, and on main the two are 1.31/1.32 s — the latch fix
is worth 0.03 s, and the control shows the A/B is measuring the right thing.

The bug this nearly shipped as

The first cut recorded the pre-full arena reading at the two
gc_start_budgeted_cycle_for_pressure call sites. Both correct, both the wrong
sites: the escalation the shipped safepoint path actually takes lives in
gc::gc_collect_minor_with_trigger_inner, so the reading was never recorded,
update_major_pacing_backoff early-returned on every cycle, and the change
measured 1.31 → 1.28 s — the mutex fix alone — with every test green.

The recording now happens inside arena_growth_full_escalation_due on the
true verdict, so a call site added later is priced by construction. The GC
trace gained a major_pacing block (baseline_bytes, backoff_shift,
escalate_above_bytes) so the subject can be asserted live rather than
inferred from a green run — that block is what showed the backoff sitting at 0
through all seven cycles.

One full is the right answer, not zero

Turning major pacing off entirely (PERRY_GC_MAJOR_PACING_FLOOR_MB=0, so
arena_growth_full_escalation_due is a constant false) makes retain
slower, not faster: 1.14 s and 390 MB peak RSS, against 0.81 s / 342 MB
with the backoff and 1.31 s / 373 MB on main. The array's abandoned backing
buffers are the one thing on this workload that only a full reclaims, so the
surviving full earns its 161 ms — the two on main did not. The backoff lands
between the extremes rather than at one of them, which is the point.

The discriminator, checked on the workload it must NOT touch

tree.ts runs 40 escalated fulls (all arena_bytes) in a 1.64 s run,
562 ms of pause. Every one of them takes arena in-use from ~41 MB to ~5 MB —
an 88% yield. The backoff reads 0 through all forty and tree is
bit-for-bit unchanged. retain's two fulls yield 5.9% and 0.0% and the backoff
moves on the first one. That is the whole heuristic, observed on both sides.

Measurements — quiet M1 mini, best of 5, absolute seconds

Peak RSS goes down, not up: retain 373 → 342 MB, retain_wide 538 → 470 MB,
retain_prealloc 416 → 408 MB. Every stdout is byte-identical to
node --experimental-strip-types.

GC traces, before → after:

gc_ratchet (shared_ci), measured on both arms on the same host: main
currently fails four 12_large_live_set cells against the pinned baseline
(heap_total_bytes +19.05%, promoted_objects +10.79%, promoted_bytes
+11.17%, freed_bytes +10.86%); this PR returns all four to ok and drops
that probe's peak RSS 191 → 170 MB. Its post-gc() heap_used_bytes goes
33.6 → 50.4 MB, still under the 51.7 MB baseline and still reported as an
improvement. Every other cell's verdict is identical on both arms, including
the 04_dead_after_deep_stack / 11_collect_at_depth regressions that are
already red on main and are byte-identical between arms.

gc-handoff/apps/iso_miss.ts prints checksum 437840 misses 0.

Test status

cargo test --release -p perry-runtime --no-fail-fast: 1961 pass, 3 fail.
The three are gc::tests::runtime_roots::generator_attach_prototype::*, and
they are pre-existing on main — a test binary built at c156f8a41 fails
the same three, and they also fail on this branch with major pacing switched
off entirely (PERRY_GC_MAJOR_PACING_FLOOR_MB=0, which makes
arena_growth_full_escalation_due a constant false). All three are
live-subject assertions about the arena trigger arming / safepoint deferral,
not about which collection kind runs.

Not fixed here, measured and named

retain is still ~5.8× node. The residue is one number: ~220 ns of
per-object bookkeeping for every promoted object, 2.5 M of them on this
workload — arena_alloc_gc_old, layout_transfer,
old_page_account_promoted_object, the move hooks, and two page-generation
classifications per visited slot. The structural answer is V8-style whole-page
promotion (relabel a nearly-all-live Eden block as old-gen instead of
evacuating it object by object), which needs none of that per-object work.

Second on the list: gc::verify::restore_surviving_dirty_coverage walks
every slot of a parent on a pre-cycle dirty page, where the scan it repairs
(scan_dirty_object_slots) walks only the slots on dirty pages — 8.8% of a
pure-retain profile, re-walking the whole 3 M-element backing store on every
minor.

Summary by CodeRabbit

• Performance

  • Improved garbage-collection pacing by adapting full-collection frequency based on reclaimed memory.
  • Reduced overhead when no prototype registry entries exist.
  • Productive collections promptly restore normal pacing, while low-yield collections apply bounded backoff.

• Diagnostics

  • Added major_pacing data to garbage-collection diagnostic output, including thresholds and current pacing state.

• Documentation

  • Added release notes describing the GC performance improvements, benchmark results, and remaining optimization areas.